The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Transmission Control Protocol (TCP) is a transport layer protocol that provides a reliable connection-oriented data delivery service to upper-layer applications through the use of sequenced acknowledgment with retransmission of segments when necessary. In a typical TCP implementation, a TCP connection is established between two TCP endpoints that are established on two hosts. A TCP endpoint is maintained by the TCP module (or stack) of a host and is represented as the combination of an Internet Protocol (IP) address of the host and a TCP port number.
TCP uses a stream data transfer mechanism to deliver an unstructured stream of bytes between TCP endpoints. The bytes in the stream are numbered sequentially and are grouped into TCP segments for transmission over the TCP connection between the TCP endpoints. A TCP segment transmitted over a TCP connection includes a header portion and a payload portion, and can be identified by the sequence number of the first byte in the payload portion of the segment. The transport service provided by TCP is used by upper-layer applications to exchange application-specific data over the TCP connection.
One example of an upper-layer application that uses TCP to exchange data is Border Gateway Protocol (BGP). BGP is a peer-to-peer routing protocol the latest version of which, BGP-4, is defined in RFC1771 that was published by the Internet Engineering Task Force (IETF) in March 1995. In order to exchange routing information, two BGP hosts, or peers, first establish a TCP connection, and then negotiate a BGP session in order to exchange network routes. Another example of an upper-layer application that uses TCP to exchange data is Label Distribution Protocol (LDP). LDP is a protocol defined for the MultiProtocol Label Switching (MPLS) architecture and is described in RFC3036 published by IETF in January 2001. In a MPLS network, two Label Switching Routers (LSRs), or LDP peers, establish a bi-directional LDP session over a TCP connection in order to exchange label-mapping information that maps network layer routing information directly to data-link layer switched paths.
TCP, however, is vulnerable to data injection attacks. In a data injection attack, an attacker guesses parameter values for a valid TCP connection and uses these parameter values to send spurious TCP segments that contain malicious or spurious data payloads. These spurious TCP segments may affect the state of the TCP connection itself or may be intended for an upper-layer application. If the receiving TCP endpoint passes such segments to the upper-layer application various problems may occur when the application acts on or executes the data payloads. The consequences of data injection attacks can be severe. For example, when a BGP session is disrupted by a change in the state of the associated TCP connection, the BGP peers that established the session may have to discard all BGP routes that were exchanged during the session and may have to re-synchronize their routing information with peer routers in the network.
One type of a data injection attack is a TCP RST attack. In a TCP RST attack, an attacker uses the parameters of a valid TCP connection to construct and send spurious TCP segments that request closing and re-setting of the TCP connection by setting the RST (reset) bit in the TCP segment's headers.
One prior approach for preventing such data injection attacks minimizes the chances that an attacker would be able to determine the parameters of a valid TCP connection. In this prior approach, a TCP endpoint computes a digital signature or message digest for each TCP segment that it sends, and includes the signature in the TCP segment header. The signature is computed based on a key or a password known only to both TCP endpoints, and uses the contents of one or more fields of the TCP segment as input. Thus, in order to successfully launch a data injection attack, an attacker would not only have to determine the valid TCP connection parameters, but would also have to guess the key or password used to produce the TCP segment-signature.
One particular implementation of this prior approach, which implementation is used for protecting BGP sessions, is described in RFC2385 published by IETF in August 1998. In this implementation, a TCP OPTION has been defined for carrying a Message-Digest5 (MD5) hash value in a TCP segment. The MD5 algorithm (as defined in RFC1321 published by IETF in April 1992) takes as input a message of arbitrary length and produces as output a 128-bit signature, or “message digest”, of the input. In this implementation, every TCP segment sent on a TCP connection contains, in the OPTIONS field of the TCP segment header, a 16-byte MD5 signature produced by applying the MD5 algorithm to the following items in order:                1. The TCP segment pseudo-header (in the order: source IP address, destination IP address, zero-padded protocol number, and segment length);        2. The TCP segment header (excluding the OPTIONS field, and assuming a checksum of zero);        3. The TCP segment data (if any); and        4. An independently-specified key or password known to both TCP endpoints and presumably specific to the TCP connection.        
Upon receiving a TCP segment signed with a MD5 signature, the receiving TCP endpoint computes its own digest for the TCP segment from same data and by using its own key. The receiving TCP endpoint then compares the computed digest with the MD5 signature included in the OPTIONS field of the TCP segment. If the computed digest matches the MD5 signature included in the TCP segment, the receiving TCP endpoint validates the TCP segment and passes the payload portion of segment to the recipient upper-layer application. If the comparison fails, the TCP endpoint silently discards the TCP segment and sends back no acknowledgement.
The above approach, however, has numerous disadvantages. One disadvantage of the above approach is that, although difficult, it may not be impossible for an attacker to produce a valid signature for a malicious TCP segment that it wants to inject in the TCP connection. For example, since the MD5 algorithm is prone to a successful cryptanalytic attack, it is not impossible for an attacker to sniff a large number of similar TCP segments and to deduce the key used to create the MD5 signatures for TCP segments. This disadvantage causes serious security concerns, especially for upper-layer applications, such as BGP, that use TCP connections to run sessions for very long periods of time.
Another disadvantage of the above approach is that in some situations it is very difficult to change the TCP connection keys without significant disruption to upper-layer applications. Since both TCP endpoints must use the same key to produce signatures for the TCP segments associated with a TCP connection, when the key associated with a TCP connection needs to be changed, both TCP endpoints must change the key nearly simultaneously in order to prevent loss of data transmitted between the upper-layer applications over the TCP connection.
For example, in a BGP implementation that is in accord with RFC2385, when BGP peers establish a BGP session with each other over a TCP connection, both BGP peers may configure their respective TCP endpoints to use a shared MD5 encryption key or password. The shared MD5 encryption key may be provisioned to the BGP peers beforehand. Some situations may arise, however, which require that the MD5 encryption key must be changed. For example, a MD5 encryption key may need to be changed because of security concerns related to personnel changes (e.g. a network administrator leaving the company). In another example, if the BGP session is a long running session and is established between a BGP peer in an Internet Service Provider (ISP) network and a BGP peer in a customer network, it may be desirable to change the MD5 encryption key periodically in order to prevent a potential attacker from guessing the key by sniffing and analyzing a large number of TCP segments sent over the TCP connection associated with the BGP session.
However, once the BGP session is established there is no practical way to change the MD5 encryption key because BGP uses its own KEEPALIVE mechanism to detect whether the BGP session is active. BGP peers disable the TCP HoldTimer for the TCP connection, and use their own BGP KEEPALIVE HoldTimer, the value of which is negotiated during the establishing of the BGP session. A BGP peer would periodically send BGP KEEPALIVE messages to ensure that the HoldTimer on its BGP peer does not expire. For example, if the BGP peers negotiate the default BGP HoldTimer interval of 180 seconds, absent the exchange of any other BGP messages a BGP peer would send a BGP KEEPALIVE message every 60 seconds or so. If the BGP peer does not receive a communication over the BGP session within the BGP KEEPALIVE HoldTimer interval, it sends out a HoldTimer Expired Error and closes the BGP session.
Thus, if the MD5 encryption key, which is used by a BGP peer in BGP session established over a TCP connection, needs to be changed, the key must be changed on both TCP endpoints within an interval of time that is smaller than the BGP HoldTimer. The interval of time during which the keys are changed on both TCP endpoints must be smaller than the BGP HoldTimer in order to prevent the TCP endpoint from silently discarding TCP segments signed with the old key that carry BGP messages of the BGP session. However, in a large network such as an ISP, it is practically impossible to change the MD5 encryption keys on all TCP endpoints that support BGP peers within an interval of time as small as a BGP HoldTimer interval.
U.S. application Ser. No. 11/173,690 of Satish Mynam et al. (“Mynam et al.”) proposes a key change solution in which a first TCP module accepts messages signed with both an old MD5 encryption key and a new MD5 encryption key. This is done without signaling to a second TCP module that the first TCP module is prepared to receive messages signed with a new MD5 encryption key. Thus, Mynam et al. proposes to allow a TCP module to enter a “key overlap” phase until a message using the new MD5 encryption key is received. However, drawbacks of Mynam et al. include the chance of denial of service attacks during the overlap of the old and new MD5 encryption keys with using spoofed MD5 encryption key based TCP segments.
Based on the foregoing, there is a clear need for techniques that overcome the disadvantages of the prior approach described above for preventing data injection attacks.